One TurboQuant lookup implementation instead of six - #55

The audit listed this as "the LUT backends are not actually vectorised — each one
gathers four scalar table lookups into a stack array and does a single vector add".
The description was accurate. The conclusion was wrong, and measuring it is what
showed why.

There is nothing here for SIMD to do

The TurboQuant scan is one table lookup per row. NEON has no gather instruction at
all, and on real data the loop already runs at about one lookup per cycle — the
load unit's limit. What the per-backend versions were actually buying was four
parallel float lanes instead of one serial double accumulator.

Four independent double accumulators buy the same parallelism without giving up
the accuracy. Measured against the NEON version over 4096 distinct rows at dim 768:

End to end over 40k rows all three bit widths land within noise of where they were.
bits=2 may be a few percent slower; the run-to-run spread is wider than the
difference, so I would not claim it either way.

The number that matters

Every backend now returns the same distance for the same query. Across 300 cases
spanning all three bit widths and dimensions 64 to 1536, SIMD-versus-scalar
divergence goes from 1.5e-4 relative to exactly zero. The old spread came from
accumulating in float over up to 384 terms while the scalar path used double,
so which distance you got depended on which CPU ran the query — enough to reorder
near-ties.

Five near-identical copies is also what let them drift apart in the first place.

A third copy of the same loop lived in sqlite-vector.c as a fallback for a null
dispatch pointer that init_distance_functions() always sets. Gone too.
Net 197 lines removed.

What would actually make this faster

A different storage layout — interleaving codes across vectors so the lookups
become in-register shuffles rather than memory gathers, the FastScan approach.
That changes the on-disk format, so it is a product decision rather than a patch.

Worth knowing while that decision is open: with the integer kernels fixed in #54,
TurboQuant is now slower than plain u8 quantization, over 40k rows at dim 768:

TURBO4 stores half the bytes of u8 and runs 9× slower, because it does 384 gathers
into a 393 KB table per row. That is a design trade-off, not a bug, and nothing
here changes it — but the space/time balance is steeper than the docs suggest, and
anyone picking TURBO4 expecting speed as well as compactness is getting the
opposite.

Note on the public API

vector_turboquant_backend() keeps returning exactly the strings it returns today.
What changed is that the value no longer identifies a TurboQuant-specific code path,
because there is only one now — it reports the SIMD tier selected at load time, the
same one vector_backend() reports. API.md now says that. If you would rather drop
the function, that is a separate call and I have not made it here.

Verification

• Build clean on arm64, x86_64 and universal.
• 1447/1447 on unittest, unittest-simd, and under ASan.
• Every distance kernel still within tolerance against a double-precision reference.
• Divergence sweep: 300 cases, SIMD vs scalar, exactly zero difference.

🤖 Generated with Claude Code